home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Internet Info 1994 March
/
Internet Info CD-ROM (Walnut Creek) (March 1994).iso
/
inet
/
internet-drafts
/
draft-glenn-layer-security-00.txt
< prev
next >
Wrap
Text File
|
1993-09-28
|
60KB
|
1,536 lines
Internet Engineering Task Force K. R. Glenn
INTERNET-DRAFT NIST
September 23,1993
Integrated Network Layer Security Protocol
K. Robert Glenn (NIST)
glenn@osi.ncsl.nist.gov
Status of This Memo
This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), it's Areas,
and it's Working Groups. Note that other groups may also distribute
working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months.
Internet-Drafts may be updated, replaced, or obsoleted by other
documents at any time. It is not appropriate to use Internet-Drafts as
reference material or to cite them other than as a "working draft" or
"work in progress."
To learn the status of any Internet-Draft, please check the
1id-abstract.txt listing contained in the Internet-Drafts Shadow
Directories on nic.ddn.mil, nnsc.nsf.net, nic.nordu.net,
ftp.nisc.sri.com, or munnari.oz.au.
It is intended that this document will be submitted to the IESG for
consideration as a standards document. Distribution of this document
is unlimited.
ABSTRACT
The Internet has been moving towards a more standardized and open
infrastructure to cope with its growing requirements. One requirement
of particular interest and importance is that of network security.
With the possible addition of CLNP [ISO8473] as a connectionless
network protocol for the Internet the most useful solution is an
integrated network security protocol that will provide security
services and mechanisms for both IP and CLNP.
The protocol defined by this Internet Draft is used to provide security
services in support of an instance of communication between network
layer entities for either IP or CLNP. An attempt is made to keep the
functionality as close as possible to [ISO11577]. As a result this
specification contains all of the technical complexities and problems
of [ISO11577]. Editorial comments are included to address certain
technical issues, such as headers ending on word boundaries,
type-length-value encoding problems, etc. that may be outside the
scope of [ISO11577]. This specification should be viewed as an initial
attempt at identifying a protocol that can provide a set of security
services for both IPV4 and CLNP.
K. R. Glenn Expires: March 28,1994 [Page 1]
INTERNET-DRAFT I-NLSP September 23,1993
1 Introduction
The Internet has been moving towards a more standardized and open
infrastructure to cope with its growing requirements. One requirement
of particular interest and importance is that of network security.
With the possible addition of CLNP as a connectionless network protocol
for the Internet the obvious solution is an integrated network security
protocol that will provide security services and mechanisms for both IP
and CLNP.
The protocol defined by this Internet Draft is used to provide security
services in support of an instance of communication between network
layer entities for either IP or CLNP. An attempt is made to keep the
functionality as close as possible to [ISO11577]. As a result this
specification contains all of the technical complexities and problems
of [ISO11577]. Editorial comments are included to address certain
technical issues, such as headers ending on word boundaries,
type-length-value encoding problems, etc. that may be outside the
scope of [ISO11577]. This specification should be viewed as an initial
attempt at identifying a protocol that can provide a set of security
services for both IPV4 and CLNP.
2 Scope and Field of Application
This Internet Draft specifies a protocol to be used by End Systems and
Intermediate Systems in order to provide security services in either
the Network layer of the OSI protocol suite or the IP layer of the
TCP/IP protocol suite. The protocol defined in this Internet Draft is
called the Integrated Network Layer Security protocol (I-NLSP).
This Internet Draft specifies the following services:
1. data origin authentication
2. access control
3. connectionless confidentiality
4. traffic flow confidentiality
5. connectionless integrity
Although the degree of protection afforded by some security services
depends on the use of some specific cryptographic techniques, correct
operation of this protocol is not dependent on the choice of a
particular encipherment or decipherment algorithm; that is left as a
local matter for the communicating systems. Furthermore, neither the
choice nor the implementation of a specific security policy are within
the scope of this Internet Draft. The choice of a specific security
policy, and hence the degree of protection that will be achieved, is
left as a local matter among the systems that are using a single
instance of secure communications.
K. R. Glenn Expires: March 28,1994 [Page 2]
INTERNET-DRAFT I-NLSP September 23,1993
3 I-NLSP Overview
One basic mode of operation of the I-NLSP protocol which is for use in
providing a secure connectionless network service. The connectionless
network service for required by I-NLSP may be either IPV4 or CLNP and
is referred to as the Datagram Forwarding Protocol (DFP). The
mechanisms and functionality of I-NLSP are identical for IP and CLNP
with the exception of the protected PDU format, which is different
because of the unique requirements for the IP and CLNP protocols (ie.,
header format and address sizes).
I-NLSP can be implemented in End Systems and in Intermediate Systems.
Only those end systems and intermediate systems that require secure
communications will be required to alter their existing IP or CLNP
implementations. End systems running IP and/or CLNP without I-NLSP
will be able to continue communicating with other end systems and
intermediate systems running IP and/or CLNP with or without I-NLSP in a
non-protected fashion. Intermediate systems with existing
implementations of IP and/or CLNP will not require any changes to be
able to forward datagrams protected by I-NLSP.
I-NLSP is designed so that it can be optimized to meet a range of
requirements from environments where the main concern is high security
to environments where the main concern is optimized performance. The
I-NLSP protocol makes use of the concept of a Security Association (SA)
which is independent of the I-NLSP protocol. A set of attributes
defining parameters for security (eg algorithm, keys etc) are defined
for the SA.
This protocol supports the use of a wide range of specific security
mechanisms (both standardized and non-standardized). Users and
implementors should choose the security mechanisms for use with this
protocol appropriate to enforce their security services and level of
protection required. The security protection which I-NLSP attempts to
provide is derived from a combination of the protection requested by
the I-NLSP user and the protection imposed by some security
administration.
3.1 Services provided by I-NLSP
This protocol provides the aforementioned security services by
encapsulating the data and optionally the datagram header in a Secure
Data Transfer (SDT) PDU. Protection mechanisms are then applied to the
body of the SDT PDU. The entire SDT PDU is then forwarded to a peer
entity as the data portion of DFP datagram.
On receipt of a SDT PDU, destined for this I-NLSP entity, the I-NLSP
protocol parses the SDT PDU, extracts and removes the protection from
the data and passes this unprotected data to the DFP for further
processing.
K. R. Glenn Expires: March 28,1994 [Page 3]
INTERNET-DRAFT I-NLSP September 23,1993
3.2 Services assumed by I-NLSP
This protocol assumes to operate somewhere within the network layer of
either the TCP/IP protocol suite or the OSI protocol suite. Two
services are assumed by the I-NLSP. The first service is access to the
Security Association information. The second service is the DFP which
provides the vehicle for which protected information is forwarded.
3.3 Security Associations
In order to protect an instance of connectionless communication a
suitable SA must exist. A SA is a negotiated set of parameters that
define the security services and levels of protection between two
entities. The SA may be established either "out-of-band" means or
using an "in-band" SA Protocol (SA-P). SA establishment, as well as a
description of a SA-P, is outside the scope of this specification.
3.4 Functional Overview
I-NLSP supports the ability to transfer protected or unprotected
connectionless datagrams between peer DFP users. I-NLSP determines
locally using Quality of Service (QOS), destination address, and other
management information (such as Network Management protocols and the
Security Association Protocol) whether protection is needed or not.
When the DFP receives data to be forwarded (regardless of whether it
came from the user of the network layer or the subnetwork), the DFP
uses the I-NLSP to determine if communication is permitted with the
destination address and if so whether protection is required. If no
protection is required, the data will be sent back to the DFP without
change. If protection is required, I-NLSP encapsulates the DFP
datagram by use of the Encapsulation Function which: takes an
unprotected octet string, applies in order the traffic flow
confidentiality, integrity and confidentiality protection mechanisms as
appropriate to the protection required and returns a protected octet
string. Intermediate system functionality requires that the entire DFP
datagram, including the header, be encapsulated. In end systems
encapsulating the header is optional. The protected octet string
becomes an integral part of the I-NLSP's SDT PDU. The SDT PDU then
becomes the data part of a DFP datagram that is then forwarded towards
the I-NLSP peer entity.
On receipt of data from a peer network layer entity, I-NLSP uses the
source address and local information to determine if communication is
permitted with the destination address and if so whether protection was
applied. If protection was not applied, the datagram is processed
normally by the DFP.
If protection was required, the I-NLSP entity extracts the protected
octet string from the SDT PDU. I-NLSP then extracts the encapsulated
datagram from the protected octet string using the Decapsulation
Function. The Decapsulation Function takes a protected octet string
and applies the appropriate mechanisms to remove the applied protection
K. R. Glenn Expires: March 28,1994 [Page 4]
INTERNET-DRAFT I-NLSP September 23,1993
and returns an unprotected octet string. The decapsulated datagram is
then processed normally by the DFP. In the case of intermediate system
functionality this could result in the activation of the encapsulation
process before the datagram is forwarded. In the case of multiple
encapsulations, multiple decapsulations would be required.
3.5 Security Services and Mechanisms
This section describes the mapping between the security services
provided by I-NLSP and the mechanisms used to support these services.
These mechanisms are not the only mechanisms which can be used to
provide security within the I-NLSP. Other mechanisms may be
standardized in future and it is possible for private mechanisms to be
used with I-NLSP.
I-NLSP supports the following security services, if selected, with the
mechanisms described:
1. Data Origin Authentication - the mechanism used to provide this
service is ICVs in conjunction with key management.
2. Access Control - the mechanisms used to provide this service are
Security Labels bound to the data and/or the control of keys
and/or use of authenticated addresses.
3. Connectionless Confidentiality - the mechanism used to provide this
service is encipherment. This protection optionally includes all
DFP header service parameters.
4. Traffic Flow Confidentiality - the mechanism used to provide this
service is traffic padding and/or hiding the DFP-address.
5. Connectionless Integrity the mechanism used to provide this service
is an ICV. This protection optionally includes all I-NLSP service
parameters.
The essential feature of the mechanisms supported by I-NLSP is an
encapsulation/decapsulation function which supports secure data
transfer by using the following mechanisms:
1. Padding for traffic flow confidentiality, block integrity
algorithms, and block encipherment algorithms.
2. Integrity Check Value.
3. Encipherment/Decipherment.
The mechanisms are carried out in the order given above.
K. R. Glenn Expires: March 28,1994 [Page 5]
INTERNET-DRAFT I-NLSP September 23,1993
4 Security Association Attributes
The following SA Attributes control the operation of I-NLSP and the
mechanisms used to provide protection. Their description includes
mnemonics used to refer to these attributes in this specification.
The associated values to these attributes shall be set up on SA
establishment.
1. SA Identification:
o My_SAID: Integer of range 0 to (256 ** maxlength) - 1
The local identifier of the SA.
o Your_SAID: Integer of range 0 to (256 ** maxlength) - 1
The remote identifier of the SA.
Note that maxlength is an integer of range 2 to 126. It is a
serious error for there to be more than one SA with the same local
identifier.
Editor's Note: For all practical purposes, maxlength should be set
to no more than 5 octets. This would provide 256**5 possible
associations. A fixed maxlength would also eliminate the need
for the LI field of the SDT PDU. A fixed length of 5 octets
would also resolve the problems associated with not aligning
the SDT PDU header on a word boundary. (the header would
always be 8 octets and thus end on a word boundary). It is
recommended that the LI field should remain and always be set to 5,
so that the ability to implement the dynamic nature intended by
this text remains.
2. Indicator of whether the I-NLSP initiated or responded to the SA
establishment:
o Initiator: Boolean
This attribute indicates how the initiator to responder flag should
be set to detect reflected PDUs.
3. DFP Address of peer I-NLSP entity:
o Peer_Adr: Octet string of format specified by DFP.
4. DFP Address of entities served through the remote peer:
o Adr_Served: Set of octet strings of format specified by DFP.
5. Protection QOS selected for the SA:
o QOS_Label: Format defined by an Agreed Set of Security Rules
(ASSR).
K. R. Glenn Expires: March 28,1994 [Page 6]
INTERNET-DRAFT I-NLSP September 23,1993
o DOAuth: Integer of range defined by an ASSR defined Data Origin
Authentication level.
o CLConf: Integer of range defined by an ASSR defined
Connectionless confidentiality level.
o CLInt: Integer of range defined by an ASSR defined
Connectionless integrity level.
o AC: Integer of range defined by an ASSR defined Access Control
level.
o TF_Conf: Integer of range defined by an ASSR defined Traffic
Flow Confidentiality Level.
Editor's Note: The QOS should only be used to recommend the
levels of security service. The actual levels are negotiated and
set by the Security Association.
6. Parameter Protection.
o Param_Prot: Boolean
Protect the I-NLSP Source address, I-NLSP Destination address, and
I-NLSP QOS parameters within the Secure Data Transfer PDU.
7. Label mechanism attributes:
o Label_set: Set of
{Label_Ref: Integer
Label_Auth: Object Identifier
Label_Content: Format defined by Label_Auth}
8. Mechanism Flags selected for the SA:
o Padd: Boolean
Padding within the Protected-Octet-String to support the Traffic
Padding mechanism.
o ICV: Boolean
Integrity within a Protected-Octet-String contents using an
integrity check value.
o Encipher: Boolean
Encipherment of a Protected-Octet-String to provide
confidentiality.
K. R. Glenn Expires: March 28,1994 [Page 7]
INTERNET-DRAFT I-NLSP September 23,1993
9. Padding Mechanism Attributes:
o Traff_Padd: Form defined by an ASSR.
Traffic Padding requirements.
10. ICV mechanism attributes:
o ICV_Alg: Object Identifier
The value of this attribute shall be defined by an ASSR. This
attribute implies certain attributes of the integrity mechanism
such as separate generate and check algorithms, initialization
vectors, etc.
o ICV_Blk: Integer
Basic block size on which the ICV algorithm operates. The
value of this attribute shall be defined by an ASSR.
o ICV_Len: Integer
The value of this attribute shall be defined by an ASSR. The
length of the output of the ICV mechanism. It is not necessary
that ICV_Len equal ICV_Blk.
o Data_ICV_Gen_Key: form defined by ASSR ICV generation key
reference for data.
o Data_ICV_Check_Key: form defined by ASSR ICV check key
reference for data.
The initial value of these "key" attributes shall be set up on SA
establishment and can be changed during the lifetime of the
association.
11. Encipherment Mechanism Attributes:
o Enc_Alg: Object identifier allocated under [ISO9979].
The value of this attribute shall be defined by the ASSR. This
attribute implies certain attributes of the encipherment
mechanism such as the form and length of any synchronization
field, separate encipherment and decipherment algorithms,
initialization vectors, etc.
o Enc_Blk: Integer
Block size of encipherment algorithm. The value of this
attribute shall be defined by the ASSR.
o Data_Enc_Key: form defined by ASSR Encipherment key reference
for data.
K. R. Glenn Expires: March 28,1994 [Page 8]
INTERNET-DRAFT I-NLSP September 23,1993
o Data_Dec_Key: form defined by ASSR Decipherment key reference
for data The initial value of these "key" attributes shall be
set up on SA establishment and can be changed during the
lifetime of the association.
5 Structure and Encoding of SDT PDUs
The I-NLSP protocol uses 2 Secure Data Transfer PDU types, one for IP
and one for CLNP. All SDT PDUs shall contain an integral number of
octets. The octets in a PDU are numbered starting from one (1) and
increasing in the order in which they are sent and received. When
consecutive octets are used to represent a binary number, the lower
octet number has the most significant value. The bits in an octet are
numbered from one (1) to eight (8), where bit one (1) is the low-order
bit.
When the encoding of a PDU is represented using a diagram in this
section; Octets are shown with the lowest numbered octet to the left or
above; and within an octet, bits are shown with bit eight (8) to the
left and bit (1) to the right. The notations below a box show the
length of each field in octets; "var" indicates that the field length
is variable.
The presence or absence of an "optional" field shall be specified by
the attributes contained in the Security Association. Note: The
optional fields are optional in that a given security association will
require the presence of certain fields and the absence of other
fields. Once the Security Association is decided, the presence or
absence of each field is determined by the SA Attributes.
5.1 Secure Data Transfer PDU
The format of a Secure Data Transfer PDU shall be as shown in Figure 1.
+-----------------------------------------------+
| Unprotected Header | Protected-Octet-String |
+-----------------------------------------------+
Figure 1: Secure Data Transfer PDU Structure
K. R. Glenn Expires: March 28,1994 [Page 9]
INTERNET-DRAFT I-NLSP September 23,1993
5.1.1 Unprotected Header
The format of the Unprotected Header shall be as shown in Figure 2.
+---------------------------------------+
| Protocol | Length | PDU | SAID |
| ID | Indicator | Type | |
+---------------------------------------+
1 1 1 var
Figure 2: Unprotected Header
1. Protocol Id - This field shall contain the I-NLSP protocol
identifier, value 01000101.
Editor's Note: As long as I-NLSP and NLSP remain functionally
aligned, the PIDs can be the same. Once the functionality
diverges a new PID needs to be determined.
2. Length Indicator - This field contains the length of the PDU Type
field plus the SAID.
3. PDU Type - This field shall contain the PDU type value of 01001000
or 01001010 to indicate a Secure Data Transfer PDU for CLNP or IP
respectively.
4. SAID - The SAID field shall contain the Security Association
Identifier of the remote entity (that is, the SA attribute
Your_SAID).
Editor's Note: A fixed SAID length would also eliminate the need
for the LI field of the SDT PDU. It is recommended that the LI
exist and always be set to 5, so that the possibility of
implementing the dynamic nature intended by this text remains.
5.1.2 Protected-Octet-String
The Protected-Octet-String field shall contain the output from an
Encapsulate Function. The structure of the Protected-Octet-String is
dependent on the specific mechanisms used and is shown in Figure 3.
The Integrity Mechanism is applied to the Unprotected-Octet-String.
The Encipherment Mechanism is applied to the entire
Protected-Octet-String.
+--------------------------------------------+
| Crypto | Unprotected-Octet | ICV | Enc |
| Sync | String | | Pad |
+--------------------------------------------+
Figure 3: Protected-Octet-String
K. R. Glenn Expires: March 28,1994 [Page 10]
INTERNET-DRAFT I-NLSP September 23,1993
1. Crypto Synchronization: This is an optional field which may
contain Synchronization data for specific encipherment algorithms.
Its presence, form, and length are implied by Enc_Alg.
2. Unprotected-Octet-String: Figure 4 shows the format for the
Unprotected-Octet-String. The encoding of the
Unprotected-Octet-String shall be a two octet length of the entire
Unprotected-Octet-String, followed by one octet, (Data Type) then a
series of TLV encoded Content Fields. The structure of the
Unprotected-Octet-String is described in more detail in the
following section.
3. Integrity Check Value (ICV): This field contains an Integrity Check
Value (ICV). The length of this field shall be defined by the ICV
Length contained in the Security Association attributes.
4. Encipherment Pad: This field contains padding for the purposes of
supporting block encipherment algorithms for confidentiality. The
choice of padding value is a local matter. All I-NLSPEs must be
able to discard this field. The format of this field shall be
defined in section 5.1.3. The Type code of this TLV field shall be
as defined in section 5.1.3. If a two octet pad is required the
length shall be zero with no value. If a single octet pad is
required a single octet PAD field shall be used instead of an
Encipherment PAD field.
5.1.3 Content Fields
There are two types of Content Fields, Mechanism-Independent
(MI-Content) which contain the data to be protected, and
Mechanism-Dependent (MD-Content) which contains information required by
the security mechanisms.
The Content Length and at least one MI-Content Field are required.
+--------------------------------------------------------------+
| Content | Data | MI-Content | ... | MD-Content | ... |
| Length | Type | Field | | Field | |
+--------------------------------------------------------------+
2 1 var var
Figure 4: Unprotected-Octet-String
1. Content Length
This field shall contain the length of the PDU contents from the
Data Type field up to the end of the last MD-Content Field.
K. R. Glenn Expires: March 28,1994 [Page 11]
INTERNET-DRAFT I-NLSP September 23,1993
2. Data Type
Bit 8 of this fields shall be the "Initiator to Responder" flag. A
value of 1 indicates Initiator to Responder. A value of 0
indicates Responder to Initiator. Bits 1-7 of this field are
0000001.
Editor's Note: The existence of this field in [ISO11577] was to
relay two items of information. The first, located in bit 8, was
which peer entity initiated the SA. It is not clear as to what
type of threat this is designed to protect against. The second was
used to identify between Connectionless and Connection-Oriented
types of data. It is recommended that this field could contain
information pertaining to the locations and sizes of the Content
Fields. This would eliminate most of the TLV problems associated
with this protocol. An example would be:
Value Meaning
----- -------
x000 0001 connectionless Data with TLV encoding
x000 0010 - x000 0111 reserved for Connection Oriented Protocol
x000 1000 connectionless Data with fixed positions,
variable lengths.
x000 1001 connectionless Data with fixed positions
and fixed lengths.
3. Content Field Format
The Content Field is a general field format for data values
to be placed in the SDT PDUs. Both types of Content Fields are
Type-Length-Value Encoded as shown in Figure 5.
+---------------------------+
| Type | Length | Value |
+---------------------------+
1 1-3 var
Figure 5: Content Field
K. R. Glenn Expires: March 28,1994 [Page 12]
INTERNET-DRAFT I-NLSP September 23,1993
(a) Type - The MI-Content Field Type shall be set to one of
the following values:
Value MI-Content Field Type
--------- ---------------------
1100 0000 Userdata
1100 0010 Source DFP Address
1100 0011 Destination DFP Address
1100 0101 QOS
1100 0110 Label
1100 0111 Label Reference
Editor's Note: An additional MI-Content Field Type may be
required to represent a DFP datagram with DFP header.
The MD-Content Field Type Shall be set to one of the following
values:
Value MD-Content Field Type
--------- ---------------------
1101 0001 Single Octet Pad
1101 0010 Traffic Pad
1101 0011 Integrity Pad
1101 0100 Reserved (See Encipherment Pad)
(b) Length - The Content Field Length shall contain the length of
the Content Field Value in octets. The Content Field Length
shall be one, two or three octets long.
i. If one octet long then bit 8 shall be 0 and the remaining 7
bits define a value length up to 127 octets.
ii. If two octets long then the first octet shall be encoded as
1000 0001 and the remaining octet defines the fields length
up to 255 octets.
iii. If three octets long then the first octet shall be encoded
as 1000 0010 and the remaining two octets define the field
length up to 65,535 octets. Other values of the first octet
are reserved for future use.
Editor's Note: The processing requirements needed to parse this
type of TLV encoding are extreme. It is recommended that the
Length field be altered to be fixed in size depending on the type
of the Content Field.
(c) MI-Content Field Values
i. Userdata - This field contains the DFP Data.
Editor's Note: Optionally this field can contain the DFP
datagram header.
K. R. Glenn Expires: March 28,1994 [Page 13]
INTERNET-DRAFT I-NLSP September 23,1993
Editor's Note: The fixed Length size, as recommended above,
for this field would be 2 Octets (a Length value of 1 to
65,536).
ii. Source DFP Address - This field contains a DFP address.
Depending on the PDU Type this field is either a Network
Layer address encoded in one of the forms described in
[ISO8348Ad2] or a fixed length 4 octet IP address.
Editor's Note: The fixed Length size for this field, as
recommended above, would be 1 Octet.
iii. Destination DFP Address - This field contains a DFP
address. Depending on the PDU Type this field is either a
Network Layer address encoded in one of the forms described
in [ISO8348Ad2] or a fixed length 4 octet IP address.
Editor's Note: The fixed Length size for this field, as
recommended above, would be 1 Octet.
iv. I-NLSP Security QOS - This field shall be used to carry the
I-NLSP QOS parameter set. This field shall contain a
sequence of octets indicating the levels of protection QOS
required in terms of security services. The semantics of
the levels is defined as part of the security policy. The
octets for each of the security services shall appear in
the order indicated below. The sequence of octets can be
truncated if the truncated octets all relate to the services
that have the QOS value 0. A single octet of value 255 shall
indicate that protection QOS requirements have been
pre-established.
Octet Meaning
1 Connectionless Confidentiality
2 Connectionless Integrity
3 Data Origin Authentication
4 Access Control
5 Traffic Flow Confidentiality
Editor's Note: The fixed Length size for this field, as
recommended above, would be 1 Octet.
v. Label - This field shall be used to carry the security label
of a PDU. This field is not present if a Label Reference
Content field is present.
+-----------------------------------------------+
| Authority | Defining | Label | Label |
| Length | Authority | Length | Content |
+-----------------------------------------------+
Figure 6: Label Value
K. R. Glenn Expires: March 28,1994 [Page 14]
INTERNET-DRAFT I-NLSP September 23,1993
The structure and interpretation of the Contents of the
Label are defined by various Defining Authorities.
Editor's Note: The fixed Length size for this field, as
recommended above, would be 2 Octets.
vi. Label Reference - This field identifies one of the set of
security labels defined in the SA attribute Label_Set. This
field shall always be encoded so that the value part of the
field is two octets. This field shall not be present if a
Label Content field is present.
Editor's Note: The fixed Length size for this field, as
recommended above, would be 1 Octet.
(d) MD-Content Field Values
i. Single Octet Pad - This field shall be a 1 octet (type
without Length or Value) field for general padding (for
example, to support a single octet of integrity padding).
This octet may be used instead of a TLV encoded Integrity,
Encipherment, or Traffic Pad field to provide integrity,
encipherment, or traffic padding. All I-NLSPEs shall detect
and discard this field.
ii. Traffic Pad - This field contains padding for the purposes
of traffic flow confidentiality. The choice of padding
value is a local matter. All I-NLSPEs shall detect and
discard this field. If a two octet pad is required the
length shall be zero with no value. If a single octet pad
is required a Single Octet Pad shall be used instead of a
Traffic Pad.
iii. Integrity Pad - This field contains padding for the purposes
of supporting block integrity algorithms. The choice of
padding value is a local matter. All I-NLSPEs must be able
to discard this field. If a two octet pad is required the
length shall be zero with no value. If a single octet pad is
required a Single Octet Pad shall be used instead of an
Integrity Pad.
6 I-NLSP Protocol Functionality
This section describes the protocol utility functions for I-NLSP.
6.1 Using QOS to determine Security Policy
The following QOS security sub-parameters are modifications to any
existing Quality of Service security parameters. Table (a) identifies
the placement of these parameters depending on whether data is to be
encapsulated or decapsulated. Within the QOS parameter protection may
be specified by either explicitly stating the following protection QOS
sub-parameters indicating the level of protection for each service
K. R. Glenn Expires: March 28,1994 [Page 15]
INTERNET-DRAFT I-NLSP September 23,1993
requested or explicitly stating a security label which implies
protection requirements.
1. Data Origin Authentication
2. Access Control
3. Connectionless Confidentiality
4. Traffic Flow Confidentiality
5. Connectionless Integrity
Table a -- Security Quality of Service Parameters
Security Quality of Service Encapsulated Decapsulated
--------------------------- ------------ ------------
Data Origin Authentication X X
Access Control X X
Connectionless Confidentiality X X
Traffic Flow Confidentiality X X
Connectionless Integrity X X
Security Label X X(=)
Note 1: In this table X indicates QOS parameter may be present; (=)
indicates that Indication parameter must be the same as the Request
parameter. Note 2: It is possible for an administratively imposed
security policy to be enforced by the I-NLSPE, in which case the policy
may dictate a level and type of security protection which is not
identical to that requested by the DFP user. However the security
label is a sensitivity indication and its value will be that given by
the user or his agent and will not be changed by the I-NLSPE.
Editor's Note: It is recommended that the Security QOS be used in the
Security Association negotiations, but not in the decision for the
actual security mechanisms applied to the data.
6.2 Checks
At many points in the following descriptions, the I-NLSP entity checks
that some condition is satisfied. Unless otherwise specified, whenever
such a check fails, the I-NLSP entity shall discard the data currently
being processed. Optionally, the entity may also file an audit
report. What failures are to be audited is considered to be a local
matter.
6.3 Identification of the Security Association
An I-NLSPE receiving a request for an instance of communication
identifies among the SAs available to it an SA whose attributes satisfy
the following conditions:
1. If the I-NLSP Protection QOS is specified then this Protection Set
equals the following SA attributes: QOS_Label, DOAuth, AC,
CLConf, TF_Conf, and or CLInt.
K. R. Glenn Expires: March 28,1994 [Page 16]
INTERNET-DRAFT I-NLSP September 23,1993
2. The I-NLSP Destination Address is contained within the set of DFP
addresses in Adr_Served. The procedure to be followed if more than
one SA satisfies these conditions is a local matter. If no such SA
exists and if "in band" SA establishment is supported then the
Security Association Protocol (SA-P), option may be selected. An
SA may be established "in band" using a SA-P. Otherwise
"out-of-band" SA establishment procedures may be followed. If
neither of these procedures cannot be completed successfully within
a locally defined timeout then error recovery procedures as defined
in section 6.2 will be carried out.
6.4 Use of a Security Association Protocol
When two I-NLSPEs do not have an SA established, they may establish an
SA by notifying a Security Association Protocol (SA-P) or some other
method. A SA-P will then optionally perform the necessary steps to
establish, modify, or terminate a SA. An SA-P may be based on either
symmetric or asymmetric algorithms. The SA-P is a separate protocol,
typically at the application layer, used to provide security attribute
management. The SA-P is mentioned within this document so that the
relationship between the SA-P and I-NLSP is better understood.
Editor's Note: It is recommended that the Security QOS be used by the
SA-P to help establish or modify a SA.
6.5 Initial Checks
An I-NLSP entity (I-NLSPE) receiving a request for an instance of
communication shall check that:
1. The I-NLSP Source Address is an DFP address served by this I-NLSPE
as determined by local security policy.
2. The I-NLSP security label or protection QOS is within the set of
labels or protection QOS that can be processed by this I-NLSPE as
determined by local security policy.
3. If unprotected instances of communication are allowed to the I-NLSP
Destination Address and the I-NLSP Protection QOS parameter does not
indicate any protection requirements then I-NLSP shall allow the DFP
to forward the datagram without change.
6.6 Processing a DFP request for Encapsulation
Once it has been determined that Encapsulation is required and a SA
exists for this instance of communication, a SDT PDU shall be
generated.
6.6.1 Generate Secure Data Transfer PDU
The following procedures shall be formed when generating a Secure Data
Transfer PDU:
K. R. Glenn Expires: March 28,1994 [Page 17]
INTERNET-DRAFT I-NLSP September 23,1993
1. The Data Type Field bit 8 shall be set to the Initiator value
contained in the SA.
2. The Data Type Field bits 1-7 are set to the value defined in 5.1.3.
3. If (Param_Prot is TRUE) then at least
one of the following shall be performed depending on local security
policy:
(a) Place the source DFP address in the Source Address Content Field
as defined in 5.1.3.
(b) Place the destination DFP address in the Destination Address
Content Field as defined in 5.1.3.
(c) Place the I-NLSP QOS parameter set in the QOS Parameter Content
Field as defined in 5.1.3.
4. Place the DFP Userdata in the User Data Content Field as defined in
5.1.3. The DFP header is also included in this field if either
this or the peer I-NLSPE is operating as an IS or optionally
otherwise.
Editor's Note: Another SDT PDU field may be required to determine
whether the DFP header is included. The DFP existing header is
necessary for forwarding after running the I-NLSP decapsulate
function. Information other than Source address, Destination
address and QOS are required for further processing (ie.,
segmentation and reassembly information). This could easily be
implemented using another MI-Content Field Type.
Editor's Note: It is unclear that if the DFP header is included in
the Userdata Content field that the other fields are necessary. It
is equally unclear that if the I-NLSP QOS is only to be used by the
SA-P, why should it be transmitted as part of an SDT PDU.
5. If (Label is TRUE) then either:
(a) a security label, shall be placed in a Label Content Field and
included in the PDU, or
(b) a security label reference, shall be placed in a Label Reference
Content Field and and included in the PDU.
6. The Encapsulation function shall be called with the following
arguments being passed:
(a) SAID shall be set to My_SAID.
(b) unprotected-octet-string shall be set to the constructed PDU
fields.
K. R. Glenn Expires: March 28,1994 [Page 18]
INTERNET-DRAFT I-NLSP September 23,1993
7. The Encapsulation function shall return either an error or a
Protected-Octet-String. Upon successful completion of the
Encapsulate function the following processing shall be performed to
create an Unprotected Header for the SDT PDU.
8. The Protocol ID field shall be set to the value defined in 5.1.1.
9. The LI field shall be set to the value of 1 + the length of
Your_SAID as defined in 5.1.1 and appended to the Protocol ID field.
10. The PDU Type field shall be set to the value defined in 5.1.1 and
appended to the LI field.
11. The SAID field as defined in 5.1.1 shall be set to the value in
Your_SAID and appended to the PDU Type field.
12. The protected-octet-string shall be appended to the SAID field.
13. The data parameter shall be set to equal the SDT PDU constructed by
the above. Upon successful completion of the Encapsulate function
the data parameter shall be set to equal the protected-octet string.
6.6.2 Encapsulation Function
This section defines an Encapsulation function. This Encapsulation
function is based on three functions: Padding, ICV, and Encipherment.
The decision to employ a particular function shall be based on
attributes of the SA. If traffic padding is selected, a traffic padding
field may be added. If a block integrity algorithm is used, an
integrity padding field may be added.
If integrity checking is selected, an ICV shall be computed over and
appended to the above fields. If a block encipherment algorithm shall
be used, an encipherment padding field may be added. If encipherment
is selected, the above fields are enciphered using the encipherment key
for the Security Association. The procedure described above
encapsulates user data and other I-NLSP protocol parameters to provide
protection for transfer over a network. At the remote end, the
recipient of a Secure Data Transfer PDU removes and checks protection
by reversing the procedure order.
Editor's Note: To simplify this protocol it is recommended that only
one pad field be used for all padding functionality.
6.6.2.1 Procedures
As encapsulation takes place, a PDU shall be formed by appending or
pre-pending fields. These fields may be optional. A partially formed
PDU is referred to be low as "existing fields". During decapsulation a
PDU shall be decomposed by removing fields. A partially decomposed PDU
is referred to below as "remaining data". Note: The description of
appending and pre-pending fields is not meant to constrain
implementations of I-NLSP but rather to unambiguously specify the
protocol.
K. R. Glenn Expires: March 28,1994 [Page 19]
INTERNET-DRAFT I-NLSP September 23,1993
6.6.2.2 Functionality
The SAID shall be used to reference a Security Association. If the
Security Association does not exist then the error SA-not-available
shall be returned and the value of protected-octet-string shall be
undetermined.
The unprotected-octet-string shall be placed in an
Unprotected-Octet-String Field. The Unprotected Octet String Length
field shall be pre-pended and its value shall be made equal to the
length of the Unprotected Octet String. If (Padd is TRUE) then an
amount and form of padding as determined locally by the ASSR rules
referred to in Traffic_Padd shall be placed in a Traffic Padding
Content Field and appended to the existing fields. If a single octet
of padding is required, then the Single Octet Padding Content Field
shall be used.
A Content Length shall be pre-pended to the existing fields. The
length of all existing fields shall be determined and placed in the
Content Length.
If (ICV is TRUE) and (ICV_Blk >1) then, if necessary, an Integrity Pad
field shall be appended to the existing fields such that the length of
the existing fields with the Integrity Pad field (including the
protected content field) is an integral multiple of the ICV block size
(that is, ICV_Blk). If present, then an amount and form of padding as
determined by local security policy shall be placed in the Integrity
Pad Content Field. If a single octet of padding is required, then the
Single Octet Pad Content Field shall be used. The Content Length value
shall be increased by the amount of padding added.
If (ICV is TRUE) then an ICV of length ICV_Len shall be calculated
over, and appended to, the existing fields. The algorithm used shall
be identified by ICV_Alg and the key used shall be the
Data_ICV_Gen_Key.
If (Encipher is TRUE) then a crypto synchronization Field with a form
and length as determined by the Alg_Id shall be generated and
pre-pended to the existing fields. If (Encipher is TRUE) then an
encipherment pad shall be appended to the existing fields so that the
length of the existing fields (that is, Protected Data Length,
Unprotected-Octet-String, Integrity Pad, and ICV fields) plus the
length of an encipherment pad shall be an integral multiple of the
encipherment block size (that is, Enc_Blk). If present, then the
amount and form of padding as determined by local security policy shall
be placed in an Encipherment Pad Content Field. If a single octet of
padding is required, the Single Octet Padding Content Field shall be
used.
If (Encipher is TRUE) then the existing fields are enciphered. The
algorithm used shall be identified by Enc_Alg and the key used shall be
either the Data_Enc_Key The constructed PDU shall be returned as the
result in protected-octet-string.
K. R. Glenn Expires: March 28,1994 [Page 20]
INTERNET-DRAFT I-NLSP September 23,1993
6.6.3 Sub-Network Request
The SDT PDU shall be encapsulated as a DFP datagram and forwarded by
the DFP to the peer I-NLSPE. The DFP datagram Source Address shall be
the DFP-address of this I-NLSPE. The content of non-security relevant
QOS parameters shall be determined by local policy but may be obtained
from the I-NLSP QOS. The DFP datagram Destination Address shall be set
to the DFP-address of the peer I-NLSPE. Note: If record route and
source route parameters are in I-NLSP QOS parameters and are not passed
as QOS parameters, then the specified QOS may not be provided for the
part of the route between source and destination I-NLSP entities.
6.7 SDT PDU/DFP Encapsulate Request Relationships
Figure 7 shows how the SDT PDU encodings described above are derived
and how they relate to each other when processing a DFP Request for
encapsulation.
6.8 Processing a DFP request for Decapsulation
In addition to the initialize checks performed for any instance of
communication the following checks are also performed.
6.8.1 Destination Address Check
The I-NLSP shall check that the DFP Destination Address is a DFP-address
served by this I-NLSP entity.
6.8.2 Check Received Secure Data Transfer PDU
The following procedures shall be formed when parsing a Secure Data
Transfer PDU:
1. The I-NLSPE shall identify among the SAs available to it an SA with
My_SAID equal to the SAID Field in the received PDU. All further
operations refer to this identified SA.
If Param_prot is TRUE then the I-NLSPE shall set the actual DFP
addresses to the values contained in the SDT PDU. Otherwise the
addresses contained in the DFP header will be used. The I-NLSP
entity shall check that the DFP Source Address is the address of an
DFP User entity reachable via the peer I-NLSP entity.
If Param_prot is TRUE, then the actual protection QOS shall be
derived from the Protected Octet String of the SDT PDU. Otherwise
any protection QOS contained in the DFP datagram header will be
used.
2. The Unprotected Header shall be discarded from the PDU.
3. The Decapsulate Function shall be called with the following
arguments being passed:
K. R. Glenn Expires: March 28,1994 [Page 21]
INTERNET-DRAFT I-NLSP September 23,1993
(a) SAID shall be set to My_SAID
(b) protected-octet-string shall be set to the remainder of the PDU.
4. The Decapsulate function shall return either an error or an
unprotected-octet-string. Upon successful completion of the
Decapsulate function the following processing shall be performed.
5. The Data Type Field, bit 8 (Initiator to Responder) flag shall be
checked to NOT equal the value of Initiator in the SA.
6. Data Type Field, bits 1-7 shall be checked to be a value defined in
5.1.3.
7. If (Label is TRUE) then the PDU shall be checked to ensure that one
and only one Label or Label Reference Content Field is present; else
the remaining data shall be checked to ensure that no Label or
Label Reference Content Field is present. If present, the value of
the label shall be checked to ensure it is contained in the set
Label_Set.
8. If (Param_Prot is TRUE) the PDU shall be checked to ensure that at
least one of the following fields is present:
(a) Destination Address.
(b) Source Address.
(c) QOS.
9. The PDU shall be checked to ensure that, at most, one Destination
Address Content Field is present. If present, the value shall be
checked to ensure that it is an DFP address served by this I-NLSPE
as determined by local security policy.
10. The PDU shall be checked to ensure that, at most, one Source Address
Content Field is present. If present, the value shall be checked to
ensure that it is an DFP address contained in Adr_Served.
11. The PDU shall be checked to ensure that, at most, one QOS Parameter
Content Field is present. If present, the Protection QOS values
within this field shall be checked to ensure they equal the
following SA attributes: QOS_Label, DOAuth, AC, CLConf, TF_Conf,
and CLInt.
12. If (Param_Prot is FALSE) the PDU shall be checked to ensure that no
Destination, Source, or QOS Parameter Content Fields are present.
13. The PDU shall be checked to ensure that, at most, one Data Content
Field is present; else the PDU shall be checked to ensure that a
Data Content Field is not present.
6.8.3 Decapsulate Function
If any of the following checks fail all security relevant status
information will be set to the security status information before
K. R. Glenn Expires: March 28,1994 [Page 22]
INTERNET-DRAFT I-NLSP September 23,1993
reception of this message, except for alarm, auditing, and/or
accounting information. The SAID argument shall be used to reference a
Security Association. If the Security Association does not exist then
the error SA-not-available shall be returned and the value of
unprotected-octet-string shall be undetermined. If (Encipher is TRUE)
then the following steps are taken:
a) The protected-octet-string shall be decrypted. The decipherment
algorithm used shall be identified by Enc_Alg and the key used shall
be the Data_Dec_Key.
b) The Crypto Synchronization field shall be removed by discarding a
number of octets, as determined by the Enc_Alg, from the front of the
deciphered data.
c) The Encipherment Pad or Single Octet Pad Content Field shall be
removed by adding the Contents Length and ICV_Len then discarding any
octets in the remaining deciphered data which are beyond the
calculated length.
If (ICV is TRUE) then the following steps are taken:
a) The ICV field shall be verified by checking the last ICV_Len octets
of the remaining data. The algorithm used shall be identified by
ICV_Alg and, if cryptographically based, the key used to calculate
the ICV shall be the Data_ICV_Check_Key.
b) If the ICV verification fails, then the error
data-unit-integrity-failure shall be returned and the value of
unprotected-octet-string shall be undetermined. The ICV shall be
removed by discarding any octets in the remaining data which are
beyond the length contained in Content Length + 2. Content fields
that the decapsulate function does not recognize are ignored.
The Content Length field shall be removed by discarding the first two
octets of the remaining data. Any Traffic Padding, Integrity Padding,
or Single Octet Padding Content Fields are removed from the remaining
data by removing data beyond the Unprotected Octet String. Note: The
Content Fields are located by decoding the contents of the Unprotected
Octet String, which is a one-octet Type field followed by a number of
TLV fields. The value of the Unprotected-Octet-String shall be
returned as the result in unprotected-octet-string.
Data from the unprotected-octet-string is extracted and sent to the DFP
for further processing. This could result in: Passing the data to the
user of the DFP; Forwarding the data toward the protected destination
(possibly re-encapsulating the datagram); or being passed back to
I-NLSP for additional decapsulation.
6.8.4 SDT PDU/DFP Decapsulate Request Relationships
Figure 8 shows how the SDT PDU encodings described above are derived
and how they relate to each other when processing a DFP Request for
decapsulation.
K. R. Glenn Expires: March 28,1994 [Page 23]
INTERNET-DRAFT I-NLSP September 23,1993
+-------------------------------------+
| DFP Header | User Data |
+-------------------------------------+
|
| Generate MI-Content Fields
V
+---------------------------------------+
| Data | MI-Content | MI-Content | ... |
| Type | Field | Field | |
+---------------------------------------+
|
| Encapsulate Function
V
+--------------------------------------------------------------------+
| Crypto | Content | Data | MI-Content | .. | MD-Content | .. |
| Sync | Length | Type | Field | | Field | |
+--------------------------------------------------------------------+
|
| Generate SDT PDU
V
+--------------------------------------------------------------+
| PID | Length | PDU Type | SAID | Protected-Octet-String |
+--------------------------------------------------------------+
|
| Forward SDT PDU
V
+-------------------------+
| DFP Header | SDT PDU |
+-------------------------+
Figure 7: Encodings and Relationships
K. R. Glenn Expires: March 28,1994 [Page 24]
INTERNET-DRAFT I-NLSP September 23,1993
+-------------------------+
| DFP Header | SDT PDU |
+-------------------------+
|
| Discard DFP Header
V
+--------------------------------------------------------------+
| PID | Length | PDU Type | SAID | Protected-Octet-String |
+--------------------------------------------------------------+
|
| Decapsulate Function
V
+--------------------------------------------------------------+
| Content | Data | MI-Content | ... | MD-Content | ... |
| Length | Type | Field | | Field | |
+--------------------------------------------------------------+
|
| Parse Unprotected-Octet-String
V
+---------------------------------------+
| Data | MI-Content | MI-Content | ... |
| Type | Field | Field | |
+---------------------------------------+
|
| Send User Data to DFP
V
+------------------------------------------------+
| DFP Header(optional) | User Data |
+------------------------------------------------+
Figure 8: Encodings and Relationships
K. R. Glenn Expires: March 28,1994 [Page 25]
INTERNET-DRAFT I-NLSP September 23,1993
References
----------
[ISO8473] ISO/IEC. Protocol for providing the connectionless-mode
network service. International Standard 8473, ISO/IEC
JTC 1, Switzerland, 1986.
[ISO8348Ad2] ISO/IEC. Information processing systems -- data
communications -- network service definition addendum 2:
Network layer addressing. International Standard
8348/Addendum 2, ISO/IEC JTC 1, Switzerland, 1988.
[ISO9972] ISO/IEC. Information technology - Data Cryptographic
Techniques - Registration Procedures for Cryptographic
Algorithms.
[ISO11577] ISO/IEC. Information technology - telecommunications and
information exchange between systems - network layer
security protocol. Draft International Standard 11577,
ISO/IEC JTC 1, USA, November 1992.
K. R. Glenn Expires: March 28,1994 [Page 24]